Signed-off-by: Joshua Schmid <[email protected]>

Signed-off-by: Joshua Schmid <[email protected]>

Signed-off-by: Joshua Schmid <[email protected]>

The experimental input allows more flexibility when adding new
experimental features, as well as the ability to remove them again
without breaking things.

For unknown specified experimental properties, the action can log
warnings.

The input property also clarifies to users that this concerns an
experimental feature, meaning that bugs may be present or that the
feature breaks user space when enabled.

The spread operator can be used quite simply to set some defaults and
overwrite them.

The merge commit sha was requested in the mergeStrategy method to
determine the merge strategy, and when the strategy is squashed, it
would retrieve the same sha again.

We can avoid one of these calls to the GH API by requesting this value
early. We need anyways to continue determining the method strategy.

This way, we can also reuse the value for the rebased strategy when we
implement a different picking approach there.

Note that the merge_commit_sha can be either a string or null, but when
we've determined that it's a squashed merge, we know that the
merge_commit_sha is set. So we can use the ! (non-null assertion
operator) to instruct typescript that it's really just a string at this
point.

I believe this functionality makes most sense to users. If a rebase is
detected they expect the rebased commits to be cherry-picked rather than
the commits from the pull request.

To find these commits, we can use git log over a range of commits.
Starting from the merge_commit_sha (which is the commit that the base
branch was updated to) we want to cherry-pick n number of commits.

Let's say there are 3 commits on the base branch after merging the pull
request:
* abc
* def
* ghi
* ..

We can find these three commits by traversing all commits from abc
excluding any commits reachable from the parent of ghi. In other words
we can do `git log ^ghi^ abc`. Note that we don't know the sha of ghi
nor its parent, but we know how to reach it. We can find the parent of
ghi as abc~3. This means we can do: `git log ^abc~3 abc` for which the
shorthand notation is `git log abc~3..abc`. Note that the number 3 can
be replaced by the number of commits on the pull request.

To do this, we must ensure that these commits are known locally. So we
must fetch these commits (and +1 in case we're in a shallowly cloned
repo).

In order to cherry-pick the merge_commit_sha it must be available.

I think that missing this was the reason for the increased fetch of the
target. But it should not be necessary. So I've reverted that change.

When the user specifies unknown properties in the experimental input,
then we should inform them about it. It does not have to stop the action
from working, but a logged warning makes sense.

When a commit is fetched directly by sha, it is only tracked by
FETCH_HEAD. However, FETCH_HEAD gets overwritten in subsequent calls.

To ensure we store the fetched commit, we must specify a refspec in the
form of `+src:dst`. If <dst> is not an empty string, an attempt is made
to update the local ref that matches it.

To find a unique ref to use as dst we can use the src sha.

It may be that this requires --force but I think we should try without
first.

When finding the shas in a range, the resulting output appears to have
doublequotes surrounding each of the shas. We must remove these to make
them usable.

In order to skip merge commits, we check for merge commits among the
commits to cherry pick. Now that those have changed due to
squash/rebase merge methods, we should check the correct commits.

Note, it's a bit useless to check these commits for merge commits, but
we can optimize it later. I'd rather be strict about what we're
checking.

This does still fix a case where a merge commit exists on the pull
request that was rebased into a non-merge commit.

The commits are looked up for a range using log, which will
automatically start with the latest commit first. However, when
cherry-picking we want to start with the oldest commit first so we can
build on top of the commits. Otherwise, we'd easily run into conflicts.